Säkerhets-headers för webben: Content Security Policy och exekvering av JavaScript

I dagens komplexa digitala landskap är säkerheten för webbapplikationer av yttersta vikt. Ett av de mest effektiva försvaren mot olika attacker, särskilt Cross-Site Scripting (XSS), är användningen av säkerhets-headers för webben. Bland dessa utmärker sig Content Security Policy (CSP) som en kraftfull mekanism för att kontrollera vilka resurser en webbläsare får ladda för en viss sida. Denna artikel ger en omfattande guide för att förstå och implementera CSP effektivt för att skydda dina webbapplikationer och användare.

Förståelse för säkerhets-headers för webben

Säkerhets-headers för webben är HTTP-svarshuvuden som ger instruktioner till webbläsaren om hur den ska bete sig när den hanterar vissa typer av innehåll. De är en avgörande del av en djupgående försvarsstrategi och arbetar tillsammans med andra säkerhetsåtgärder för att minska risker.

Några av de vanligaste säkerhets-headers för webben inkluderar:

• Content Security Policy (CSP): Kontrollerar vilka resurser användaragenten får ladda.
• HTTP Strict Transport Security (HSTS): Tvingar webbläsare att använda HTTPS.
• X-Frame-Options: Skyddar mot Clickjacking-attacker.
• X-Content-Type-Options: Förhindrar sårbarheter relaterade till MIME-sniffing.
• Referrer-Policy: Kontrollerar hur mycket referrer-information som ska inkluderas i förfrågningar.
• Permissions-Policy (tidigare Feature-Policy): Möjliggör detaljerad kontroll över webbläsarfunktioner.

Denna artikel fokuserar främst på Content Security Policy (CSP) och dess inverkan på exekvering av JavaScript.

Vad är Content Security Policy (CSP)?

CSP är ett HTTP-svarshuvud som låter dig definiera en vitlista över källor från vilka webbläsaren tillåts ladda resurser. Detta inkluderar JavaScript, CSS, bilder, typsnitt och andra tillgångar. Genom att explicit definiera dessa betrodda källor kan du avsevärt minska risken för XSS-attacker, där skadliga skript injiceras på din webbplats och körs i kontexten av dina användares webbläsare.

Tänk på CSP som en brandvägg för din webbläsare, men istället för att blockera nätverkstrafik blockerar den exekvering av opålitlig kod.

Varför är CSP viktigt för exekvering av JavaScript?

JavaScript är ett kraftfullt språk som kan användas för att skapa dynamiska och interaktiva webbupplevelser. Dess flexibilitet gör det dock också till ett primärt mål för angripare. XSS-attacker involverar ofta att injicera skadlig JavaScript-kod på en webbplats, vilken sedan kan användas för att stjäla användaruppgifter, omdirigera användare till nätfiskesidor eller vandalisera webbplatsen.

CSP kan effektivt förhindra dessa attacker genom att begränsa källorna från vilka JavaScript kan laddas och köras. Som standard blockerar CSP all inline-JavaScript (kod inom <script>-taggar) och JavaScript som laddas från externa domäner. Du aktiverar sedan selektivt betrodda källor med hjälp av CSP-direktiv.

CSP-direktiv: Byggstenarna i din policy

CSP-direktiv definierar vilka typer av resurser som får laddas och från vilka källor de kan laddas. Här är några av de viktigaste direktiven:

• default-src: Fungerar som en fallback för andra fetch-direktiv. Om ett specifikt direktiv inte är definierat används default-src.
• script-src: Specificerar de tillåtna källorna för JavaScript-kod.
• style-src: Specificerar de tillåtna källorna för CSS-stilmallar.
• img-src: Specificerar de tillåtna källorna för bilder.
• font-src: Specificerar de tillåtna källorna för typsnitt.
• media-src: Specificerar de tillåtna källorna för ljud- och videofiler.
• object-src: Specificerar de tillåtna källorna för plugins (t.ex. Flash).
• frame-src: Specificerar de tillåtna källorna för ramar (<frame>, <iframe>).
• connect-src: Specificerar de tillåtna ursprungen för nätverksförfrågningar (t.ex. XMLHttpRequest, Fetch API, WebSockets).
• base-uri: Begränsar de URL:er som kan användas i ett dokuments <base>-element.
• form-action: Begränsar de URL:er som formulär kan skickas till.
• upgrade-insecure-requests: Instruerar webbläsaren att uppgradera alla osäkra URL:er (HTTP) till säkra URL:er (HTTPS).
• block-all-mixed-content: Förhindrar webbläsaren från att ladda några resurser via HTTP när sidan laddas över HTTPS.

Varje direktiv kan acceptera en mängd olika källuttryck, inklusive:

• *: Tillåter resurser från vilken källa som helst (rekommenderas generellt inte).
• 'self': Tillåter resurser från samma ursprung (schema, värd och port) som dokumentet.
• 'none': Tillåter inte resurser från några källor.
• 'unsafe-inline': Tillåter användning av inline-JavaScript och CSS (starkt avrådes).
• 'unsafe-eval': Tillåter användning av eval() och relaterade funktioner (starkt avrådes).
• 'unsafe-hashes': Tillåter specifika inline-händelsehanterare baserat på deras SHA256-, SHA384- eller SHA512-hash (använd med försiktighet).
• data:: Tillåter data:-URI:er (t.ex. inline-bilder kodade som base64).
• https://example.com: Tillåter resurser från den angivna domänen (och valfritt port) över HTTPS.
• *.example.com: Tillåter resurser från vilken subdomän som helst av example.com.
• nonce-{random-value}: Tillåter specifika inline-skript eller -stilar som har ett matchande nonce-attribut (rekommenderas för inline-kod).
• sha256-{hash-value}: Tillåter specifika inline-skript eller -stilar som har en matchande SHA256-hash (alternativ till nonces).

Implementera CSP: Praktiska exempel

Det finns två huvudsakliga sätt att implementera CSP:

1. HTTP-header: Skicka Content-Security-Policy-headern i HTTP-svaret. Detta är den föredragna metoden.
2. <meta>-tagg: Använda en <meta>-tagg i <head>-sektionen av HTML-dokumentet. Denna metod har begränsningar och rekommenderas generellt inte.

Använda HTTP-headern

För att ställa in CSP-headern måste du konfigurera din webbserver. De exakta stegen varierar beroende på din server (t.ex. Apache, Nginx, IIS).

Här är några exempel på CSP-headers:

Grundläggande CSP

Denna policy tillåter endast resurser från samma ursprung:

            Content-Security-Policy: default-src 'self';
            

              
                Copy
              
            
          

Tillåta resurser från specifika domäner

Denna policy tillåter JavaScript från https://cdn.example.com och bilder från https://images.example.net:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; img-src 'self' https://images.example.net;
            

              
                Copy
              
            
          

Använda nonces för inline-skript

Denna policy tillåter inline-skript som har ett matchande nonce-attribut:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-rAnd0mN0nc3';
            

              
                Copy
              
            
          

I din HTML:

            <script nonce="rAnd0mN0nc3">
 // Ditt inline-skript
</script>
            

              
                Copy
              
            
          

Notera: Nonce-värdet bör genereras slumpmässigt för varje förfrågan för att förhindra att angripare kringgår CSP:n.

Använda hashar för inline-skript

Denna policy tillåter specifika inline-skript baserat på deras SHA256-hash:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=';
            

              
                Copy
              
            
          

För att generera SHA256-hashen kan du använda en mängd olika onlineverktyg eller kommandoradsverktyg (t.ex. openssl dgst -sha256 -binary input.js | openssl base64).

Använda <meta>-taggen

Även om det inte rekommenderas för komplexa policyer kan <meta>-taggen användas för att ställa in en grundläggande CSP. Till exempel:

            <meta http-equiv="Content-Security-Policy" content="default-src 'self';">
            

              
                Copy
              
            
          

Begränsningar med <meta>-taggen:

• Kan inte användas för att specificera report-uri-direktivet.
• Har inte lika brett stöd som HTTP-headern.
• Mindre flexibel och svårare att hantera för komplexa policyer.

CSP Report-Only-läge

Innan du tvingar igenom en CSP rekommenderas det starkt att använda Content-Security-Policy-Report-Only-headern. Detta låter dig övervaka effekten av din policy utan att faktiskt blockera några resurser. Webbläsaren kommer att rapportera eventuella överträdelser till en specificerad URL, vilket gör att du kan finjustera din policy innan du driftsätter den i produktion.

            Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report;
            

              
                Copy
              
            
          

Du måste konfigurera en server-side-slutpunkt (t.ex. /csp-report) för att ta emot och bearbeta CSP-rapporterna. Dessa rapporter är vanligtvis JSON-objekt som innehåller information om det överträdda direktivet, den blockerade URI:n och andra relevanta detaljer.

Vanliga CSP-misstag och hur man undviker dem

Att implementera CSP kan vara utmanande, och det är lätt att göra misstag som antingen kan försvaga din säkerhet eller förstöra din webbplats. Här är några vanliga fallgropar att undvika:

• Använda 'unsafe-inline' och 'unsafe-eval': Dessa direktiv inaktiverar i huvudsak skyddet som CSP erbjuder och bör undvikas när det är möjligt. Använd nonces eller hashar för inline-skript och undvik att använda eval().
• Använda *: Att tillåta resurser från vilken källa som helst omintetgör syftet med CSP. Var så specifik som möjligt när du definierar din policy.
• Att inte testa noggrant: Testa alltid din CSP i report-only-läge innan du tvingar igenom den. Övervaka rapporterna och justera din policy vid behov.
• Felaktigt konfigurera report-uri: Se till att din report-uri-slutpunkt är korrekt konfigurerad för att ta emot och bearbeta CSP-rapporter.
• Underlåta att uppdatera din CSP: När din webbplats utvecklas kan din CSP behöva uppdateras för att återspegla ändringar i dina resursberoenden.
• Överdrivet restriktiva policyer: Policyer som är för restriktiva kan förstöra din webbplats och frustrera användare. Hitta en balans mellan säkerhet och användbarhet.

CSP och tredjepartsbibliotek

Många webbplatser förlitar sig på tredjepartsbibliotek och -tjänster, såsom CDN:er, analysleverantörer och sociala medier-widgets. När du implementerar CSP är det viktigt att ta hänsyn till dessa beroenden och se till att din policy tillåter dem att ladda resurser korrekt.

Här är några strategier för att hantera tredjepartsbibliotek:

• Vitlista explicit domänerna för betrodda tredjepartsleverantörer: Om du till exempel använder jQuery från ett CDN, lägg till CDN:ets domän i ditt script-src-direktiv.
• Använd Subresource Integrity (SRI): SRI låter dig verifiera att filerna du laddar från tredjepartskällor inte har manipulerats. För att använda SRI måste du generera en kryptografisk hash av filen och inkludera den i <script>- eller <link>-taggen.
• Överväg att hosta tredjepartsbibliotek på din egen server: Detta ger dig mer kontroll över resurserna och minskar ditt beroende av externa leverantörer.

Exempel med SRI:

            <script
 src="https://cdn.example.com/jquery.min.js"
 integrity="sha384-vtXRMe3mGCkKsTB9UMvnoknreNzcMRujMQFFSQhtI2zxLlClmHsfq9em6JzhbqQ"
 crossorigin="anonymous"></script>
            

              
                Copy
              
            
          

CSP och Single-Page Applications (SPA)

SPA:er förlitar sig ofta tungt på JavaScript och dynamisk kodgenerering, vilket kan göra implementeringen av CSP mer utmanande. Här är några tips för att säkra SPA:er med CSP:

• Undvik att använda 'unsafe-eval': SPA:er använder ofta mallmotorer eller andra tekniker som förlitar sig på eval(). Överväg istället att använda alternativa tillvägagångssätt som inte kräver eval(), såsom förkompilerade mallar.
• Använd nonces eller hashar för inline-skript: SPA:er injicerar ofta JavaScript-kod dynamiskt. Använd nonces eller hashar för att säkerställa att endast betrodd kod exekveras.
• Konfigurera connect-src-direktivet noggrant: SPA:er gör ofta API-anrop till olika slutpunkter. Se till att endast vitlista de nödvändiga domänerna i connect-src-direktivet.
• Överväg att använda ett CSP-medvetet ramverk: Vissa JavaScript-ramverk har inbyggt stöd för CSP, vilket gör det enklare att implementera och underhålla en säker policy.

CSP och internationalisering (i18n)

När man utvecklar webbapplikationer för en global publik är det viktigt att beakta CSP:s inverkan på internationalisering (i18n). Här är några faktorer att tänka på:

• Content Delivery Networks (CDN): Om du använder ett CDN för att leverera din webbplats tillgångar, se till att vitlista CDN:ets domäner i din CSP. Överväg att använda olika CDN:er för olika regioner för att optimera prestandan.
• Externa typsnitt: Om du använder externa typsnitt (t.ex. Google Fonts), se till att vitlista typsnittsleverantörernas domäner i ditt font-src-direktiv.
• Lokaliserat innehåll: Om du serverar olika versioner av din webbplats för olika språk eller regioner, se till att din CSP är korrekt konfigurerad för varje version.
• Tredjepartsintegrationer: Om du integrerar med tredjepartstjänster som är specifika för vissa regioner, se till att vitlista domänerna för dessa tjänster i din CSP.

Bästa praxis för CSP: Ett globalt perspektiv

Här är några allmänna bästa praxis för att implementera CSP, med hänsyn till ett globalt perspektiv:

• Börja med en restriktiv policy: Börja med en policy som blockerar allt som standard och aktivera sedan selektivt betrodda källor.
• Använd report-only-läge först: Testa din CSP i report-only-läge innan du tvingar igenom den för att identifiera potentiella problem.
• Övervaka CSP-rapporter: Granska regelbundet CSP-rapporter för att identifiera potentiella säkerhetssårbarheter och förfina din policy.
• Använd nonces eller hashar för inline-skript: Undvik att använda 'unsafe-inline' och 'unsafe-eval'.
• Var specifik med dina källistor: Undvik att använda jokertecken (*) om det inte är absolut nödvändigt.
• Använd Subresource Integrity (SRI) för tredjepartsresurser: Verifiera integriteten hos filer som laddas från CDN:er.
• Håll din CSP uppdaterad: Granska och uppdatera din CSP regelbundet för att återspegla ändringar på din webbplats och dess beroenden.
• Utbilda ditt team: Se till att dina utvecklare och säkerhetsteam förstår vikten av CSP och hur man implementerar det korrekt.
• Överväg att använda en CSP-generator eller ett hanteringsverktyg: Dessa verktyg kan hjälpa dig att skapa och underhålla din CSP enklare.
• Dokumentera din CSP: Dokumentera din CSP-policy och skälen bakom varje direktiv för att hjälpa framtida utvecklare att förstå och underhålla den.

Slutsats

Content Security Policy är ett kraftfullt verktyg för att motverka XSS-attacker och förbättra säkerheten för dina webbapplikationer. Genom att noggrant definiera en vitlista över betrodda källor kan du avsevärt minska risken för exekvering av skadlig kod och skydda dina användare från skada. Att implementera CSP kan vara utmanande, men genom att följa bästa praxis som beskrivs i denna artikel och beakta de specifika behoven hos din applikation och globala publik, kan du skapa en robust och effektiv säkerhetspolicy som skyddar din webbplats och användare över hela världen.

Kom ihåg att säkerhet är en pågående process, och CSP är bara en pusselbit. Kombinera CSP med andra säkerhetsåtgärder, såsom indatavalidering, utdatakodning och regelbundna säkerhetsrevisioner, för att skapa en omfattande djupgående försvarsstrategi.

Ytterligare resurser

• Content Security Policy (CSP) - MDN Web Docs
• CSP-utvärderare
• Content-Security-Policy.com